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Notes on Ethernet in Saturn 



3.0 : NETWORK SCENARIOS 

( For the purpose of seeing if the Datatrib has the right ports, and working out how much dif- 
ferential delay concatenated Vcs must tolerate. ) 



NOTE: THE FOLLOWING PICS ARE PROVISIONAL, NUMBER AND TYPE OF DATATRIB 
PORTS HASN'T BEEN FIXED. 

- PROVISIONING A DATATRIB AND ENGINEERING IT WITH THE" NECESSARY (HTTLESS) 
FLEXIBILITY IS GOING TO BE A CHALLENGE. 

• NEED TO DECIDE DT PATATKXB IS ENGINEERED FROM DAY 1 TOR USB WITH Rl SAT, . 
AGGS OR AGGS WITH STM-4/SLOT. . 

- THERE IS NO INTENT TO SUPPORT ETHERNET OVER ANY INTERMEDIATE PDH LINKS 
AS FAR AS THE DATA TRIB IS CONCERNED ( LOSE ALL THE BENEFITS OF SDH AND 
MAJOR JUMP IN COMPLEXITY.) 

- THE PHRASE ETHERNET PROTECTION WHICH APPEARS LATER, MEANS I DON'T 
KNOW WHAT I'M DOING- MIGHT BE. SPANNING TREE, MIGHT BE SPANNING TREE 
TRIGGERED BY SDH PATH MONITORING, MIGHT BE SDH CAUSES SWITCHES TO SWAP 
/DUMP/RELEARN ADDRESS TABLES ETC. 



BACKHAUL OPTIONS: VC-4 RING 
MATCHED NODE 
PHYS TO ROUTER 
VC4/3/21/RJNG 

SATURN 16 WITH EXISTING DATA TRTB 
SATURN 16 -WITH 100 M ACCESS 
MSP SPUR 



STM-4 RING ( MLXED VENDOR ? ) 

STM-4 ARC /SPUR? 

4XE ON MSP WITH RING TRIBS 



ACCESS: 
SPUR TO 1C 

IX RING / ARC WITH SPURS TO 1C 
IX/ 1C RING WITH ACCESS DEVICE 
ASCOMS? 
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"CONVENTIONAL" CONFIGURATION 

Saturn Node with Ethernet Switch ( datatrib ) 



Normal Node 

( any vendor bat VC-3/2/1 ) 



Backup head end Router • 
C Ethernet Protection not SDH ) 



Head End Router 




2- x VC-3 

Add b« inside VC-4) 



Dpal Home option 
Ethernet not SDH 



Head End Router 



EARLY DEPLOYMENT ( single head site « path protected ) 




xYC-12 perlC 
path protected 
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EARLY DEPLOYMENT ( dual bead site - Ethernet protected ) 



Backup headend 
Routi 



Head End Router 




xVC-12perlC 



STM-l RING ACCESS 




Backup head end Router 
( Ethernet Protection not SDH ) 



Head End Rooter 




STM-4 RING ( ! STM-16 WITH 16X ???? i ) 



THIS PIC ASSUMES 
ARINGOFlCsON 
CUSTOMER PREMi 

THE AUTHOR THINKS: 

- RINGS ON CUSTOMER 
PREM ARE A BAD IDEA. 

- SINGLE CARD 1C IS 
NOT REALLY A RING 
PRODUCT. 





[d foe inside V04} 



Option 1- Path protected 5 x Vo-13 
per 1C Saturn Rl can support 
4 x STM-1 ring- Saturn CR and 16 
can support STM-1 rings. 
Proposed Mk 1 datatrib limit is 
12 customers per mux 
Option 2: S x Vc-12 per ring. 1C 
does frame add/drop. Data trib 
4imit proposed : 6 rings- 
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STM-1 RING ACCESS coat.. 



Backup head end Router 
( Ethernet Protection not SDH ) 



Head End Router 




uld be inside VC-4) 



Option 1: Path protected 5 x Vc-lZ 
per 1C Saturn Rl can support 
4 x STM-1 ring, Saturn CR and 1$ 
can support 8 x STM-1 rings. 
Proposed Mk 1 data trib limit is 
12 customers per mux. 
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STM-4 KING ACCES9 

Backup head end Konteir Head JEnd Router 




this ring. 

Assume Saturn €R can support 
2 x SFTM-4 trib rings. Could 
allocate 1 x VC-3 per trib ring 
for Eflusmet, Need 4 x VC-3 
trib ports on Main ring datatrib- 
Saturn 16 may be able to support 
4 x STM-4 trib ring. If so, datatrib 
would need 8 x VC-3 trib ports. 
This would leave up to 4 x VC-3 
for main ring data bandwidth. 

Choice of raiimng subtending rings 
at 1 x VC-3 for data,,£eems to fit. 
But may need Mk2 data trib to 
folly exploit Saturn 16. 
Need 4 x VC-3 trib ports oil 
Mkl datatrib; 
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WHA? ARE WE GOINO TO DO ABOUT MATCHED NODES ? ( ACCESS SIDE ) 

Backup head end Router Head End Router 

( Ethernet Protection not SDH ) 



i 1 



STM-4 OR 16 RING 



STM-4 RING 



2 x VC-3 
oould be inside VC-4) 



TRAFFIC BY MATCHED NOD* 
BUT DATA BY 'ETHERNET 
PROTECTION 4 

t VC-3 

(2*tfC-3: FUTURE?) 



Backup head end Router 
( Ethernet Protection not SDH ) 



Head End Router 




2*VC 3 

iidd be inside VC-4) 



TRAFFIC BY MATCHED NOD* 
BUT DATA BY ^ETHERNET 
PROTECTION' 



lxVC-3 

VC-3: FUTURE?) 
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STM-l ACCESS ARCS 




BOTH PICS ASSUME 1C IS CUSTOMER FREM LOCATED. VIEW ON THIS EXPRESSED 
J&ARIJER. 



Backup head end Router 

( Ethernet Protection not SDH ) 



Head End Router 




J — U J 
i i 



STM-4 OR US RING 



L J 







E 






TN-1C 




TN-1C 




TN-1C 








2*VC-3 

uld be inside VC4) 



Ethernet Protection! 

Either 3 xVc-lZperlC 
or 5 x VC-12.per chain with 
1C douig^fhuneadd/drop 
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SXM-1 ACCESS ARCS carats *• 



Backup head end Router Head End Router 




TN-lC 
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STM-4 ACCESS ARCS 

FOR STM-4 MUXES WITHOUT DATATRIB5, JUST SUBSTITUTE FOR IX IN PIC ON 
PREVIOUS PAGE. 



Backup h£ad end Router 

( Ethernet Protection ndt SDH ) 



Head End Router 





1001 



r i 



U -J 

I I 



SnCM-4 OR 16 RING 



TN -1C | 




-t— 














— [e1— 








2 x YC-3 



Fits available bandwidth 
to DainCrib if 1 x VC-3 
( but consider mk2 datatrxb 
permitting this to be 2 x VC-3 
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GENERALISATION ON THE ACCESS SIDE 




I THINK THE PLANNED DATA TRIB AND 1C ACCESS DEVICE MAKE SENSE FOR 
BUSINESS ACCESS WITH 5 X VC-JL2 PER 1C WHEN DEPLOYED OFF STM-4 OR 16 RINGS. 

THE STORY ISN'T SO GOOD FOR.TWO CASES: 

- CUSTOMERS LIKE COLT, WHO HAVE DEPLOYED A LOT OF IX RINGS IN 
BUSINESS DISTRICTS. 

- CUSTOMERS LIKE CABLE COMPANIES, WHO HAVE ALSO DEPLOYED A LOT 
OF IX, AND WHO WOUlD LIKE TO OFFER ETHERNET TO SMALLER BUSINESSES. 
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coni— from previous pic 

SUGGESTION FOR 'COLT LIKE' CUSTOMERS 

. IDEAL SOLUTION: NEW STM-1 MUX WITH ETHERNET SWITCH INSIDE 
-ALTERNATIVE 

ASSUMPTION, WE ONLY NEED A SOLUTION WHEN A LOT OF' CUSTOMERS 

WANT ETHERNET. 

THEREFORE ETHERNET MUST OCCUPY MINIMUM BANDWIDTH ON STM-1 
-RING* 

THEREFORE 1C MUST HAVE ETHERNET INTO 1 X VC-12 OR INTO 2M OPTION. 

in a cbiir iype scenario, most Ethernets will be hstra-ring or 

INTER RINGS OF THE SAME HEAD END- 
SO SAY, 120 ETHERNETS OVER 4 STM-1 RINGS. AS SUME ABOUT 30 WILL 
NEED TO LEAVE THE HEAD END TOWARDS THE BACKBONE. 

CONSIDER A HEAD END FLAVOUR OF SATURN DATA TRIB WITH A LOT 
OF ETHERNET PORTS ? ( NEED ABOUT 30, EACH AT 1 X VC-12 ) 

CONSIDER FITTING AN ETHERNET SWITCH INTO IX, WITH MAYBE 
OPTIONS OF EITHER S X VC-12 OR VC-3 EN RING. ? 

CONSIDER WHAT IS GOING TO REPLACE IX ? 

OF THE ABOVE, I THINK ETHERNET SWITCH INTO Tlfcffi 1XIS PROB ABLY 
HIGHLY DESIRABLE, BUT WOULD PROBABLY HAVE TO BE INTEGRATED 
ON THE PAYLOAD MANAGER. ( P REFER TO SELL THEM A SATURN 4XE/S 
AS A REPLACEMENT ) 



SUGGESTION FOR 'CABLE TYPE* CUSTOMERS 

- PROBABLY DO NOTHING - THEY WILL DEPLOY CABLE MODEMS 

OTHERWISE IDEAL SOLUTION IS THAT UMUX SITS IN RING AND HA S 
ETHERNET SWTICH- 

- ALTERNATIVE: UMUX CONSOLIDATES SEVERAL CUSTOMER DATA SERVICES 
INTO ETHERNET IN VC-12- BACKHAUL VC42S> CONSIDER A HEAD END FLAVOUR 
OF SATURN DATA TRIB WITH A LOT OF ETHERNET PORTS ? 



CONCLUSION ON THE ABOVE* 

NO POINT DOING ETHERNET INTO SINGLE VC-12 OPTION ON MKl SATURN DATATRIB, 
BECAUSE ITS ONLY NEEDED WHEN A LOT OF PORTS ARE ALSO NEEDED. 

QUESTIONABLE DP ITS WORTH DOING ETHERNET INTO SINGLE VC-12 ON 1C 

NEED TO WORK OUT IX AND CABLE STREET CABINET STRATEGY BEFORE DOING 
ANYTHING ABOUT *LOT OF PORTS* SATURN DATA TRIB- 
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FINALLY ON ACCESS ( THERE IS A LOT MORE TO CONSIDER ON BACKHAUL 
"UPWARDS" FROM 'TOE SATURN RINGS.) 

ENERGXS-LIKE MESHES 




□ 



EjMsrgjs actually deploy spurs or rings from their 'Snaps' to reach customers! so 
the Energis 'mesh' wfll be considered later as part of backhauL 
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4.0 . :IM?)LEMENTATION IN SATURN 
4.1: Saturn Routing Capability 



* ADM versions 



West* 



STM-2 Drop 
per pair on Kl 
hardware. 
: STM-4 Drop 
per pair on 
cost reduced 
TN4and 
future. 



4/3/2/1 


Thru 


4/3/2/r 






Switch 




Switch 




^ East* 










In Xtt, Add is either 
STM-1 from each trib 
of a pair, OR, STM-2 
from onetrib of a 
pair (1+1 prot). 
In cost reduced TN4 
and future,, this is at 
least doubted* 



4.2: Data Option 
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4,2-1: Use of the Data Tab 
TRAFFIC WHICH IS NOT PATH PROTECTED 



West* 



4/3/2/1 


Thru 


4/3/2A 


Switch 


Jraffi 


Switch. 







Switct 





East* 



100 base-X : Ring Traffic 

Carried as2x VC-3 ( virtual concatenation ) 

( or option 1 x YC-3 

NOTE: The Switch could route either or both 
of these to tributaries instead* 



TRAFFIC WHICH CAN BE PATH PROTECTED 



Wast* 



4A3/2/1 


Thm 


4/3/2/1 


Switch 




Switch 



East* 




4 X Tug-3 available 
(5 if ring only uses 1 x VC-3 ) 

Each path is broadcast from the 
Data trib* Each path returned to 
the Data, trib sees a path protection 
selector. 

( Kbdug-3 with future aggs ) 



BACKPLANE UTILISATION 



E?net 
Switch 



rJ L 



Path 
prot 



Data Trib 



NEEDS FURTHER WORK 
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43: Modes of Operation 

RING HEABt Phy or Path Protected 2 x VC-3 access to Head End Router 



West Agg 
or Trib «j 



100 base X 
over 
3 x VC-3 



Phy Q-+ 



100 base X 



EthernetSwiidb 



EastAgg 
orTrib 



100 baseXT 
over 

.2xVCX3 



1 ^4 ■ ^tttff iT'* x 



y Path Protection 

£ ^ ■ '. . . r- 









4 MwTT7TTTn^ f 

, 2x 5xVC^12p*reachof 
Yc-S 9 custottiers- 



RING NODE with Fibre Spurs to CPE ( or directly hosted STM-1 riog$ with lObX in ring ) 



West Agg 
or Trib ^ 



100 base X 

oyer 

2xVC<3 



Pby 



Ethernet Switch 



100 base X 



East Agg 
or Trib 



100 base X 
oyer 
2 x VC-3 



"ttttttttttt 10 X 



■ Path ^Protection 



wwttttitntrw 

. 5 x VC-12 per each of 
12 customers* 



? Consider option 5 x VC-12 each of 16 customers, 
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RING NODE wiih Directly Hosted STM-4 rings, (max 2 rings) 



West Agg 
or Trib ^ 



100 base X 
over 

2xVC-3' ■ 



Phy 



100 base X 



Ethernet Switch. 



100 base X: 
over 



East Agg 
^ or Trib 



C2 



"45"bsse X ( switch^ permitting) 



Path Protection Disabled 



T T T 

, taeaeJbr6f4 STM-4 tribs ( rmgTreads^ ^- — — fc 



/RING NODE of directly Hosted ring 
I 



'West Agg 



"45" baseX 

over 

lxVC-3 



100 base X 



Ethernet Switch 



Blast Agg 
orTrib / 



«45" baseX 



Over 

lxVC-3 



lObX 



/Path Protection 



T T T ■ ™ f TfTff I ' 

5 x- VC-12 per each of 
13 customers, 

THIS EXAMPLE APPLIES TO A SATURN 16 KING WITH SUBTENDING S TM-4 RINGS 
THE INTENT IN THE LONGER TERM WOULD BE IN TWO STEPS, STEP 1> DAT A TRIE 
WITH STM-4 CAPACITY AND THEN INTEGR ATED DATA AGGREGATE- THE LATTER 
WOULD SUPPORT GIGABIT ETHERNET ON THE STM-16 RING 
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XJPGRADE OPTION ON PKKVIOXJS PIC: ( 2 SLOTS TJttNTPROTECTED ) 



West Agg 
orTrib 



'623* baseX 
4XVC4 



GIGABIT Ethernet Switch 




Gbit 
PIky 



Ttfb 



^23' base X 



ONE I) ATA TJRTB 



Phy* 



Gbit 



ONE OR TWO SWT CCffiS ► ON ONE 6 ATATREB 



i 


i j 




' t . 


1 


Path-Protection Disabled 


y 


r 









It t f 



/Path Protedioo Disabled 

t 






r ' • . -i 


r 





2 X VC-3 TO EACH OF SEX. Snvi-4 TJtEBS ( RING HEADS } 
1 X VC^ TO E^OT<>F TWELVE TRJB PORTS 

5 tc VC-12 TO EACH OF TWELVE STM-i TRIB PORTS 
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5.0 ^VIRTUAL- C ONCATEN ATION & FRAME PACKING 



r 



5.2: Virtual Concatenation 
5Jd: VC-12s and V03s 



SDEt Frame 



IS 



Total 270 coUudmbs 
63 « 



63 



63 




Ta -12 ; one column in each group of 63 
=36 bytes in 125 uS ( includes pointer ) 
Vc-12 =i 35 bytes in 125 uS 

VC-3 every third column in each group of 
63 pSus 1 column an group of IS pin* 
pointer cotanm in group of 18. 
VC-3 = 85x9 bytes in 125 uS 





POH 






> 


i 

l 


i 

6 
> 


JATA 


DATA 


i 


Au-4FTR 


T 

O 








m 

a 
> 


«** 

r 


6 










m 




m 
m 



Shown for case of three 
VC-3s baYC4 



10 



18 



125 uS 



VC -12 



PTR K 



[ysj 34T>ytes \ 52 



|K3 



N2 



V2 



V3 



"vl 



' i 
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5.L2: Virtual Concatenation: Origlnatbig End 

To describe the principle of virtual concatenation, the example of concatenating two VC-3s 
will be used. Firstly at the originating end, two VC-3s are created to carry the payload! They 
will be created with timing to suit the local equipment multi-frame sync and probably with a 
convenient pointer value. Both will be created 'simultaneously*. 
Only the payload region is illustrated. 



V03#3 


2 
A 


(84x9) -1 byte* 


2 
B 














1 
A 




1 
B 






First byte 



C first by te of the FOK ) 



One byte of the payload at a known location is used to append a frame number: The number of 
frames this number must increment over before repeating is determined by the differential 
delay the two VC-3s may incur crossing a network. Nominally if the differential delay is N 
frames, then the numbers must run over 2N frames before repeating. In practice some allow- 
ance must be made fox the payload bytes not being uniformly spread over the 125 uS interval 
and the number may have to run over one more frame than nominal* 

Differential delay can have two causes. For two VC-3s which run over the same physical route 
( fibre ), the differential delay may be caused by intervening NEs. This will be null for NEs 
which manipulate only VC-4$ ( if the two VC-3s ate in the same VC-4 ), otherwise it will be 
doe to variations in fill of LO ptr processor buffers. ( Any time switching should only add 1 
byte delay ~ unless its a very badly designed time switch ), For two VC-3s which run over dif- 
ferent routes ( whiqh could happen if a path protection switch only occurs on one VC ), then 
the differential delay is due to different physical distances ( fibre delay ) plus the absolute 
delays of intervening NEs. 

A data frame to be carried in the concatenated payload can start at any time relative to the VC. 
It is not desirable to incur delays and storage in holding the data frame to the next VC start It 
is inserted into the payload as shown ( but note that encoding is covered later ).. 



VC-3#2 



VC-3#1 



2 
A 


2nd. 






2 
B 








4th etc 


1 

A 








1 
B 





Lbyte 
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Virtual Concatenation t Destination End 
When the two VC-3s arrive at the destination equipment, they will have ( in the case of Saturn) 
been, pointer processed. Their pointers will therefore be at known locations, but the VCs will 
have suffered different delays. This is illustrated below, assuming that the delay is less than 
125 uS ( for ease of illustration )♦ 



JDiff, Delay 

- — a»» 



(84x9) -1 bytes 



VC-3#1 



They could arrive as shown above* 
or as shown below. 



VC-3#2 



( 84 * 9 ) -1 bytes 



Diffc Delay 



VC-3#1 



1 




1 




A 




B 





A pointer receiver is necessary to locate the payload, the payload is then identified by the fol- 
lowing byte as ' A T or C B > and it is written to a ram. The ram is organised as follows: 



Byte wide Ram 
forVC-3#2 



rorV03#l 



a* 



< 



The first byte after *2A 9 is stored here 

-Ar- 



- -v 



8- 



-4- 



The first byte after 'IB' is stored here 
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Assume VC-3 #2 arrives after VC-3 #1 . At an instant in tune the locations illustrated below 
will be being written. 



Ram #2 re- 
write address ctr. 



Byte wide Ram 
for VC-3 #2 



for VC-3 #1 



-4- • 



Ram#l ^ 
write address ctn 



The tricky bit is to control a read counter ( this is rather like a pointer generator )> so that simul- 
taneous reading of both Rams occurs in a legal region illustrated below: 



Ram #2 

write address cfir. 



Byte wide Ram 
for VC-3 #2 



Common read 
address ctr. 



for VC-3 #1 



Ram#l 

write address etc 




On the face of it, to control the read address counter, one waits for the last VG of the two to 
arrive ( when it writes to address 0 ). The read address counter can then trickle along behind 
the write address of #2 above, so long as it doesn't fall so far behind that the write counter of 
#1 catches up with it The problem is that if the system started up T just after #1 had writea to 
address 0, it would think #2 was the first arriving frame and #1 arrived later- This is why the 
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frame number has to run for > twice the designed differential delay. If 'last' arrives more than 
the designed value after 'first*, the read address counter needs resetting. Controlling the read 
address counter in normal operation should be hitless, so either a phase locked loop could be 
used or a clock gapping scheme. In either case a control circuit based on after 'last* and before 
'gist' is needed. The decision will be influenced by the nature of the encoding used to cany 
Ethernet data. 

Note: it may not be necessary for the payloadram to be twice as large as the differential delay, 
but it's a lot easier to think about if it is. 

Note: if the virtually concatenated VCs suffer a differential delay larger than the range of the 

frame numbering, this can only be detected by coixuption of the payload data. 

Note: One byte shown for frame numbering is illustrative. With one bit to indicate the VCno ( 

not strictly "necessary but a good check )„ this leaves 7 bits for frame sequence*. This may or 

may not be enough*-.. .. ' 

Note: The choice of aframe number byte- with its location determined- by its place in the VC 

structure precludes the passage of concatenated payloads overPDHlinks. 

53: Ethernet Encoding 

5.2.1: The Mil interface 
( see IEEE 802.3 lOObaseT ) 

Assumption: We are only interested in connecting ( via SDH ) an Ethernet switch to an Ether- 
net switch, or an Ethernet switch to a Mac. We are not going to have an isolated Ethernet Phy ( 
physical interface device ) at the end of an SDH link. 

Assumption: We will choose all Ethernet parts to support the Mil standard. Older lObasc X 
parts commonly used a 1 bit, 10M serial interface, but the Mil seems to be becoming the norm. 
Its standard on lOObase X and dual speed parts. 

The MH is a 4 bit wide ( nibble ) interface clocked at 2.S M for lObase and 25M for lOObase. 
Depending on vendor chosen we may be able to use a gapped clock, but the maximum rate will 
probably be limited to 25M. 

The Ethernet spec supports the following Mil signals: 
From a source: 

( the transmit clock is input into the source ) 

♦ TxJER Transmit racor ( assumption : switches and macs do not source this signal ~ it can be 
used to. cause corrupted symbols on the physical media ) 

o TxD<3:0> ( assumption: switches and macs will not source corrupted frames; therefore 
sending a non-integer number of octets - odd number of nibbles - indicates a fault ). 

• Tx^EN Transitions high at the start of a frame ( beginning at the start of the preamble ) and 
remains high until the end of the frame. 

To a destination: 

( the receive clock is input into the destination ) 

• COL ( Assumption: we are only operating in a full duplex environment, so collisions do not 
occur - any flow control is done by 802.2D Pause frame ) 

♦ CRS ( Assumption: to be investigated if we need to locally spoof carrier sense to either 
macs or switches ). 
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* Rrf3<3:0> ■ 

* RxJD V Transitions high at the start of a frame ( beginning at the start of the pre-amble ) and 
remains high -until the end of the frame. ( Assumption: switches and macs rely on this signal 
to delineate the frame, they cannot recognise frame boundaries otherwise ). Need to check 
that this is the same definition as TxJSN, eg switches and macs do not put out an End of 
frame sequence which would be embraced by TslEN but not by RxJDV. 

* RxJER ( Assumption: not used , its normally generated when a Phy detects- a symbol error 
on the physical media t although we might consider using it if we lose a VC in the middle of 
a frame. - Probably just- rely on the switch detecting the bad CRC ). 



5^.2r Encoding Constraints 

There aie two categories of choice to be made: 

■ The encoding of framie data and the delineation; of frames. 

- The clocking scheme ta be employed. 

Encoding Schemes:. 

Ethernet Thys* can detect start and end of frames by the presence of ( usually ) Manchester 
endoded data on the physical media. This is not possible for switches and macs, so when we 
transport an Ethernet frame over the SDH VCs, we need to somehow carry the information that 
this is a data frame as distinct from null or fill data. The Ethernet preamble cannot be used, 
because there is nothing to prevent user data from mimicking it. A number of schemes could 
he used: 

I*- 

• A simple segmentation and re-assembly scheme running over the payload of VC frames. 
The main objection to this, is that it is necessary to create VCs on a. constant 125 uS or 500 
uS clock. Therefore an Ethernet frame covddbe ready to transmit at any time dining a VC 
frame. Simple segmentation schemes would require the storage of the Ethernet frame until 
the next VC start which could put up to 125 uS delay into the data transfer. "With lOObaseX, 
this would both delay and require storage of potentially several frames. 

• A pointer based scheme. In such a scheme, a pointer in a known location of the VCs pay- 
load would point to the start of the Ethernet data frame. Another pointer ( or a length field ) 
would point to the end of the Ethernet data frame. Mechanisms would be provided to cope 
with frames which start and end inside one payload frame. This kind of mechanism is 
employed in ATM adaptation layers for AAL1 ( but this assumes a regular structure - 
length - to the payload ). There are two difficulties with this: Multiple Ethernet frames can 
fit inside a VC-3 payload ( you could get a couple of minimum frames into a single. VC-12 
multiframe ), so the number of pointers could be large and complex to use. You can't fill in 
the pointer value, until an Ethernet frame starts, so in order not to incur delay, the pointers 
have to go at the end of the VC frame and point backwards, this then incurs, delay and stor- 
age at the destination while waiting for the pointer to arrive. ( the storage might be incorpo- 
rated in the storage required for 'de-concatenating.' , but the delay is. probably unavoidable ). 

• A bit stuffing scheme. In this kind of scheme, the intent is to be able to recognise a string of 
ones or a string of zeroes as an interval between frames, by ensuring this doesn't occur in 
the data frame. Once it is known that no more than N ( say ) Is will occur in a row in the 
data frame, strings of ones can be used to indicate an interval between frames* and strings of 
ones with a zero can be used to indicate start and end of frame. Such a scheme is used with 
Hdlc, in which any occurence of a sring of five Is in the data causes the sending end to 
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insert a 0- Detection of five Is at The receiving end causes removal of the following zero, or 
else detection of a special symbol like end of frame. This kind of scheme appears less effi- 
cient in use of bandwidth than pointer or segmentation type schemes, but this might be illu- 
sory. Pointers and segmentation carry a penalty in bytes used, also efficiency is about 
throughput* and delay. Since with bit stuffing type schemes, both transmission and reception 
can begin as soon as the first data byte arrives, they might well minimise total delay. A sim- 
plifying variant on bit stuffing coold be considered. Conceptually the data stream running in 
the payload of the VCs could be considered as 9 bit bytes starting after the first byte of path 
overhead. The 9th bit could then be used to indicate The presence of a frame. The ineffi- 
ciency of an Hdlc like bit stuffing mechanism depends on the nature of the data in a data 
frame/the 9th bit scheme would be worse than best case Hdlc and better than worst case 
Hdlc. It might be a lot simpler to implement because the data rate over the VC payload is 
calculable. 

**• A byte stuffing scheme as per PPP over Sonet ( RFC1662). This is Hdlc but with the flag 
character ( 7E ) and the abort character ( 7D ) being replaced by and 7D being 

replaced by 7D,5D. The use of abort would permit 'forwarding' the 'error* signal equiva- 
lent of the MIL This scheme is attractive in its simplicity. 



Clocking Schemes 

Coming from a transmission background, it is natural to assume that data transmission from 
one Ethernet part to another over SDH will be continuous, with recovered clocks used at every 
stage of the process. This need not be the case. Since data frames are discrete, and all clocks 
are very accurate, it may be possible to use fixed clocks at different stages and small fifos to 
cater for differences. For instance, a gapped clock from SDH transport might be used to write 
concatenated VC-s into a Ram at the destination end. A fixed local clock might be used to 
drive tibe read address counter, with the read address being reset in the gaps between data 
frames. In either case, care will be needed to ensure that Ethernet inter-frame gap times ( 7 9.6 
uS ) are not violated ( although a switch or mac might not care - which would make our life 
easier ). 

Some examples of the above schemes are illustrated below: 
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Pointer Scheme in concatenated VC-3 Frames, 
Payload ~ (84 x9)*-l byte « 755 byte per ftame. 
Need 10 bit pointer 



Ibyte 
frame ID 



Single VC-3 payload illustrated 



End of 




16 bit 'Pointer* 
fbxmnpppppppppp : 
0>= front, back, unused 
x= spare 

nn = \>?hich. concatenated 
vc, the 1st or last byte is in 



Ibugh pointers 
" Vc-a fun of 
frames. 
Pointer byte anil . 
In concatenated flram 

Minimum frame = 64 bytes 
Minimum interframe gap is 
120 bytes at 1Q0M- ( check 
chosen parte enforce this ). 



NOTE: "NEED TO CHECK IF INTE3UTRAME GAP IS NEEDED IN FULL. DUPLEX SWITCHED 
SYSTEM, ALSO IP SWITCHES / MACS HAVE ANY CONTROL OF IT !I 



9 Bit Byte scheme in a VC-3 payload 




Two VC-3 payload illustrated 



755 byte per frame = 1510 bytes per concatenated frames 



- 12080 bite « 1342 ?noctets : throw away 2 bite at end. 




9 th bit positions, with counting starting after 
frame ID- 9 th bit set to 1 when an Ethernet 
data frame is present. 



\ 

Final notes on this secttoo: 

The susceptibility of any scheme to bit errors needs to be considered. Since an Ethernet data 



MG _5atdala.mrf 



27 * 



Notes on Ethernet in Saturn 



frame will be corrupted by bit errors anyway, the only issue is that the scheme doesn't lose 
sync and result in corruption of the next frame- 

The choice of pointer or some form of bit stuffing scheme will probably be dictated by ease of 
hardware implementation. For efficiency, the pointer scheme might require the number of 
pointers used to be variable, eg a lot of short frames in a high rate payload would need a lot of 
pointers. Rather than reserving space permanently, it could be more efficient to run pointers 
from the back of the SDH frame, forward ujitil an 'end of pointers* marker. 



SJL3z Resultant Data Rates? 

I x yc-3 with pointer scheme: 84 columns - ( 1 byte frame Id for concatentation + 36 bytes of 
pointers ) = 719 bytes in 125 uS = 46.016 Mbit/s. ( so 2 x VC-3 = 9232 Mbit/* ). This might 
reduce shghtlyif inore than 1 byte is needfeci'far frame Id, and mightbe improvedif the point- 
ers were located across both concatenated frames. 

1 x VC-3 with 9th bit scheme: 84 columns - 1 byte frame Id = 755 bytes in 125 uS. - 6040 bits 
in 125 uS 604Q/9 9bit bytes = 671 '9s* in 125 uS- This gives an Ethernet frame data rate of 
671 bytes in 125 uS = 42.951 Mbit/s ( so 2 x VC-3 = 85.9 Mbit/s ). 

An Hdlc like scheme in which the end of frame flag is ignored t the preamble is used for start 
of frame, and no bit stuffing occurs, would result in 755 bytes in 125 uS, which is 48.32 Mbit/s 
( or 2 x Vc-3 gives 96.64 Mbit/s ). This would go down to 80 Mbi1/s with worst case bit stuff- 
ing. 

1 x VC-12 with pointer scheme: 136 bytes - ( 1 byte multiframe Id for concatenation + 6 bytes 
pointers ~ 3 ptrs ) = 129 bytes in 500 uS = 258 khytes/s = 2.064 Mbit/s . 
So 5 x VC-12 gives 10.32 Mbit/s, 

I x VC-12 with 9th bit scheme: 136 bytes - 1 byte multiframe Id for concatenation = 135 bytes 
in 500 uS.= 1080 bits = 120 9bit bytes in 500 uS. This gives an Ethernet frame data rate of 120 
bytes in 500 uS = 1.92 Mbit/s- So 5 x VC-12 gives 9.6 Mbit/s. 

TO BE CALCUUffED FOR HDLC BYTE STUFFING 
53-4z Scrambling 

If the user data frames can Fill an SDH section ( eg: data mapped directly into a VC-4 sent over 
an STM-1 link ) 7 it is possible for the user to maliciously mimic the SDH scrambler sequence; 
This could result in all 0s or all Is data across the link which would cause the section clock 
recovery PLL to fail. Therefore scrambling using a self synchronous scrambler has been pro- 
posed to prevent this. 
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6.0 :BUILDING BLOCKS 



Switch 
Interface 



jptionalstrij 
preamble 



optional add 
preamble 



FIFO 



FIFO 



Hdlc 
byte stuff 



Hdlc 
de- stuff 



Virtual 
concat. 



Control of switch interface 
based oixFifo fM by clock 
gapping or data bursting. 




:oncai^* — 



Nx create 
containers 



N x pointer 
receivers 



1 'CHANNEL* 



Scramble here if 
mapping into; 
Nx.Vc4.Nx 
Ste-3c, ?Nx5ts-l 



CTock 25Mw& 
XOObMH. 
2^ M with 10b 
125Mwith,lG 



THE ABOVE SEEMS TO BE A COMMON BUILDING BLOCK FOR MOST AP^C^JIONS, 
BUT IT MIGHT BE IMPLEMENTED IN VARIOUS VERSIONS FOR DD^PERgST RATES, 
WITH OR WITHOUT VIRTUAL CONCATENATION AND WITH OR WITHOUT 
SCRAMBLER, POSSIBLY LO OR HO FTR RECEIVERS. 

NOTES: THE CLOCK ON ETHERNET SWITCHES CAN BE GAPPED, B^C^^ W 
FASTER THAN NOMINAL . THEREFORE THE CHANNEL DATA RATE ACTUALLY 
SENT OVER THE FIBRE MUST BE LESS THAN 1GBFT (100 MBIT) (10 MBIT ). 
( NOTE : CHECK MPC860 USED ON ACCESS DEVICE ) 

OPTIONALLY STRIPPING PREAMBLES ( ETHERNET )^STO MATO THE FRAMES 
ON THE FIBRE LOOK STANDARDS COMPLIANT (IF NECESSARY )> NOT TO 
IMPROVE DATA RATES, INTO AN ETHERNET SWITCH, PREAMBLE AND INTER-FRAME 
GAP MUST BE PRESENT. 

ITS ASSUMED THAT FRAMES AT THE SWITCH INTERFACE ARE COMPLETE WITH 
CRC-32. 

HDLC STUFFING SENDS FLAGS BETWEEN FRAMES. 

VIRTUAL CONCATENATION WILL BE CHALLENGING AT HIGH ^^^T^" 1 * 
/ STS-4S, A RAM FOR DE-CONC ATENA TION WOULD NEED A ^OMBYTTOS ACCESS 
AND ^KBYTES PER 125 nS DIFFERENTIAL DELAY. I THINK THIS MEANS A 
RAMBUS DRAM* 

( NEED TO CHECK : IS POH POSITION AVAILABLE FOR REAL CONC ATONEATED 
SONET FRAMES. EG: VC-4 HOLDS 260 X 9 BYTES* DOES AN STS-3C -jXXSKt 
COLUMNS TO STUFF IN THE FORMER POH POSITIONS ?- DITTO N X VC-4 ) 

FOR SATURN WANT LO PTR RECEIVERS CONFIGURABLE AS: 

1-5 X VC-12 ( ? YT-I.5 ), OR 1-2 X VC-3 ( 1-3 X STS-1 HO IN SAME PART * ). 

NEED TO CONFIGURE BY TIME SLOT, MODE AND SIZE 

FOR LO PTRS, IT MIGHT BE POSSIBLE TO HANDLEV^UAL CON^n^^Isf 
AND POINTER RECEPTION WITH A PROCESSOR AND RAM FOR SEVERAL CHANNELS- 
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BUILDING BLOCK IN SATURN 



I/F c A a 



1/F'B' 



ONE.CHANNEL 



ONE CHANNEL 





Monitor& 
Set ss bite 



Monitor^ 
Set ss bits 



[rime Slot Control I 1 ' 

A * CHANNEL FAIR 3 



LEFT AGG. 



RIGHTAGG* 



SELECTOR POSITIONS ARE AJEVLHitt FOR TB^^ 

SLOTS TO WHICH THE CHANNELS ARB ASlGNED- THEY ABE SET BY CARD 
CONTROLLER SETTING REGISTERS. 

THIS MEANS THATi 

EACH CHANNEL CAN BE ASIGNED TO EITHER THE SAME A^^g^TE^BlJT 
S^SERK?T TIME SLOTS, OR DIFFERENT AGGREGATES WITH THE SAMEOR 
SlTO^ENT S SLOT^OR EACH CHANNEL CAN BE USED PATH PROTECTING 
ON BOTH AGGREGATES- 
GENERAL IDEA IS THAT BACKPLANE CLOCK AND S^TABLY D^YED 
BACKPLANE MULTI-FRAME SYNC IS APPLIED TO ™E TI^S^T CO^OL 
BLOCK* A PROGRAMMABLE OFFSET IS AVAILABLE FOR THE 'TO BACKPLANE' 
DIRECTION. 

TIME SLOT CONTROL GENERATES STROBES ONCE EACH ^^^^^^ 
PROGRAMMED WITH TIME SLOT, MAPPING AND AGGREGAITE USAGE/m 
STROBES RUN TOWARDS THE BACKPLANE TO CONTROL THESE^CTORS 
AND THE SS BIT MONITORING / INSERTION* ( SATURN NEEDS BOTH, ? 
EXPRESS ONLY NEEDS INSERTION ? ) 

SS BIT INSERTION / MONITORING MIGHT BE BETTER DONE COMMONLY FOR 
SEVERAL CHANNELS. 

FLEXIBILITY IS BEST IF THE ABOVE 'CHANNEL PAIRS* MU X TOG ETHER INTO 
A STM-4 / STS-12 RATE BYTE STREAM, BUT IT MIGHT BE EASIER FOR 
BWLEM^mSlON IF MUXING IS BY TRI-STAOTNG INTO A STM-1 / STS-3C 
BYTE STREAM FOLLOWED BY A 'ROUND ROBIN MUX 5 TO 7SM. 

BEFORE REACHING THE BACKPLANE, SYSTEM SPECIFIC SECTION AND LINE 
OVERHEAD (BYTE STEALING ETC ) HAS TO BE CATERED FOR. 
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COMMON c CHANNEL PAIR' FOR IX, 1C, SATURN, EXPRESS 



LEFTAGGk 



RIGHT AGG 



EACH 'AGG' PORT RUNS AT 7&Mx(8+ parity ) STS-12 / STM-4 
EACH SWITCH I/F RUNS AT : ( by config register > 

- Mil 4 1)its 25 Mar ?>5 M clock 
or 

- GMH 3 bits dock at either 125 M if technology permits or ( probably fpga ) rate to 
suit STS-12 / VC-4 - 74.9 M ( but would need to run a bit fester to permit the odd clock 
gap to keep the fifos under control >. 



MAPPINGS: 

Either the 4 Agg* interface has live STS / VC-4 traffic or else the HO containers have 
been synchronised elsewhere. 

So either HO pointers have to be processed to extract data packets! from n* STS-1 or nx VC-4 
or else LO pointers have to be processed to extract data packets from n x VT-0U5 or n x VC-12 

Higher and lower order pointers do not have to be processed simultaneously on the same 
channel. 

Mappings supported (.each can be real or virtual concatenation): 
1~ n x VT-L5 with 4 x US M MH 

1-3 x STS-1 with either GMTI or 4 x ISM MH up to 100 Mbit/s 
1, 2 or 4 x yr$-3c with GMH 

1-5 x VC-12 with 4 x ( NOTE: Assume vuttuaf concatenation within a Tug-3 ? ) 

1-3 x VC-3 with either GMH or 4 x 25M MH up to 100 Mbit/s 
1, 2 or 4 x VC-4 with GMH 

NOTE: Option with n x STS-1 mappings to add fixed stuff to STS-1 to reduce payload to 
the same size as a VG*3» 



NOTE; For IX / 1C only N x VC-12 is needed, but may need to program each VC to separate 
time slots. Or group of N within one Tug-3 ? 



I/F 'A 1 



ONE CHANNEL 



ONE CHANNEL 



Monitor^ 
Set ss bits 



r 



Monitor& 
Set ss bits 



* [lime Slot Controlr ' — J '~ 1 

A 'CHANNEL PAIR' 



MG^gatdntn.rnif 



31 



4/2/03 



Notes on Ethernet in Saturn 



APPLICATION WITH VARIOUS SYSTEMS 



EXPRESS 



GMH? 




78Mx9 



ONECH 



LWiaatl]-- 1 J 

A CHANNEL PAJft 



C3> SEL 

ASIC? 



:vtx-a 



TTX-B 



MH ( to be checked ) 



78x9 



19-44x8 



MPC 860 ? 
(or small 
E'netsmUto) 




» 





format 








convert 










SIRPJCT 




78MP11 








Note2 




Note* 



Note 2: bpa > "mapper" 
just re-dock 19M data 
to78M. 

« f roapper^> bpa jn«?t 
clock out STM-1#1 at 
19M 



PM^A 



Note 1: no Sirpit on 
1C, byte parallel 
back to only one "pm r 



SATURN 



114090 

4040 or 
Dakota 
later- 



MH ( GMH with 4040 ) 



3 



ONECH. 



I Vim^bW J - J ■ * 

A CHANNEL frAltt 



USB 



Conceivably up to 15 1 'Channel 
Pairs". ProbdbKy 4 or 8 pairs. 



J ONECH. 



onbcs 



A CHANNEL FATR 



78x9 



AGG 



AGG 
-R 
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MULTIPLE CHANNEL PAIRS ON SATURN 

FROM BPA TO "CHANNEL PAIR** BLOCKr FAN OUT ONLY 

FROM "CHANNEL PAIR" TO BPA: PROPOSE "CHANNEL PAIR" INCORPORATES 
EXPANDER INPUTS AS: 



W*A' 



ONE CHANNEL 



ONE CHANNEL 



Mbniiosr& 
Set ss bits 



r 



Monitor^ 
Set ss bite 



r 



iTime Slot Control b - -* 1 

A 4 CHANNEL PAIR* 



LEFT 



RIGHT 
AGO 



LEFT RIGHT 
EXPANDER INPUTS 



- EXPANDER INPUTS RE-TIME 78M DATA 

. LEFT EXPANDER INPUT IS SELECTED EXCEPT FOR TIME SLOTS WHERE THE 
CHANNEL PAIR IS ACTIVE ON LEFT 

- RIGHT EXPANDER INPUT IS ACTIVE EXCEPT FOR TIME SLOTS "WHERE THE 
CHANNEL PAIR IS ACTIVE ON RIGHT 



CONNECT TOGETHER AS: 



Tl 



NOTE: SUGGEST ONE 'STOLEN* 
A2 BYTE ( SECTION INTEGRITY ) 
PER CHANNEL* 

IDEALLY WANT ONLY ONE 
CONNECTION ID CHECK 
(POLLED ) PER CARD 



33 



472/03 



DPM-12 



Appendix: A: Virtual Concatenation 
Al: Defiwdtiou 

The Sonet / SDH payload carried over Tfelecomms equipment xs divided into a number of chan- 
nels each represented by a virtual container ( Vc). Each of these has a defined bandwidth, so in 
order to cany a signal which has a bandwidth greater than that of a VC, the user has two 
choices. Either go to the next size up of VC, or use multiple Vcs tocairy the signal. The stand- 
ard for SDKenvisaged that in the range VC-12 ( approx 2 Mbit/s) up to VC-4 ( appro* 150 
Mbit/s ), a user would choose the next size of container.. For rates above VG-4, the standard 
provides 'real concatenated' bandwidth, which provides channels with bandwidth of multiples 
of VCM. However, neither of these measures meets user needs. This is because for the lower 
rates, the steps* in container size are too large. For instance the next size up from VC-12 at 
approx. 2 Mbit/s is" VC-2 at approx 8. Mbit/s, followed by VC-3 at approx. 50 Mbit/s. VC-2 is 
not commonly supported by equipmentin the network, leaving a.user who wishes to transport 
a 4 Mbit/s .signal having to use ( and pay for ) a VC-3 with enormous wastage. For rates above 
VC-4, although the standards support VC-4-nc ( any multiple of VC-4 ), the reality is that most 
equipment deployed in the network does not support this. 

A user needing to efficiently transport signals having a bandwidth which either fits between 
the available VG bandwidths or exceeds VC-4 bandwidth, has to use a multiple of VCs to carry 
the signal- Because each VCis accessed and traverses the network independantly* this is called 
*virtuaT concatenation. In order to use virtual concatenation, the user has to take account of the 
fact that the network is unaware that this is happening. The different VCs that are used, may be 
routed differently by the network, and even if routed together will experience different delays. 

&2z Using Virtual Concatenation 

A.2,1: Virtual Concatenation: Originating End 

To describe the principle of virtual concatenation, the example of concatenating two VC-3s 
Will be used. Firstly at the originating end, two VC-3s are created to carry the payload. They 
will be created with timing to suit the local equipment multi-frame sync and probably with a 
convenient pointer value. Both will be created 'simultaneously 7 . 
Only the payload region is illustrated. 



VC-3 #2 of 2 



(83x9)bytes 



vc3#i*ca 




Virtual concatenation overhead. Stream no ( 1-2 ) and Sequence no ( A-B ) shoTvn* 



One column of the payload at a known location is used to append Virtual Concatenation over- 
head. This includes a sequence number which identifies the SDH ( 125 uS ) frame. The number 
of frames this number must increment over before repeating is determined by the differential 



virtualconcaunif 
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delay the rwo VC-3.S may incut crossing a network. Nominally if the differential delay is N 
frames, then the numbers must jun over 2N frames before repeating. In practice some allow- 
ance must be made for the payload bytes not being uniformly spread over the 125 uS interval 
and the number may have to run over one more frame than nominal. 

Differential delay can have two causes. For two VC-3s which run over the same physical route 
( fibre ), the differential delay may be caused by intervening NEs. This will be null for NEs 
which manipulate only VC-4s ( if the two VC-3s are in the same VC-4 ), otherwise it will be 
due to variations in fill pf LO ptr processor buffers. ( Any time switching should only add 1 
byte delay - unless its a very badly designed time switch ). For two V03s. which run over dif- 
ferent routes ( which could happen if a path protection switch only occurs on one VC ), then 
Hie differential delay is due to different physical distances ( fibre delay ) plus the absolute 
delays of 'intervening 

[Note: ..;v. . 

A data packet to be carried in the concatenated payload can statt at any time-relative to the VC. 
It is not desirable to incur delays and storage in holding the data.frame to the next VC start It 
is inserted into the payload as shown ( but note that encoding of data frames is covered in a 
separate Appendix ). 
1 



VC-3#t 



2 
A 








2 
B 






4th etc 


1 
A 








1 
B 


1 



Ibyte 



AJL2: Virtual Concatenation : Destination End 

When the two VC-3s arrive at the destination equipment, they will have ( in the case of Saturn) 
been pointer processed. Their pointers will therefore be at known locations, but the VCs will 
have suffered different delays. This is illustrated below, assuming that the delay is less than 
125 uS ( for ease of illustration ). 



virtual cct\caLmif 
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Diff. Delay 
-4 *» 



(B3x9)bytes 



VC-3#1 



VC-3#2 



They could arrive as shown above, 
or as shown below* 

VC-3#2 



(S3x9)bytes 



Dii£. Xtelay 



1 




1 




A 




B 





A pointer receiver is necessary to locate the payload, the payload is then identified by the 
sequence number as *A* or *B" and it is written to a ram. The ram is organised as follows: 



Byte wide Ram 
forVC-3#2 



The first byte after t 2A* is stored here 



-As- 



for VC-3 #1 




The first byte after 4 IB' is stored here 



Assume VC-3 #2 arrives after VC-3 #1. At an instant in time the locations illustrated below 
will be being written. In order to recover the original data, it must be read in its original align- 
ment from locations where data from the same frame of both VCs is simultaneously valid. 
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Ram #2 
write address Or. 



Byte -wide Ram 
fwrVC-3#2 



f<wrVC-3#l 



- -v- 

- -v- 



Rara#3L ^4- 
write address ctr. 



- -As- 



The tricky bit is to control a read counter ( this is rather like a pointer generator ), so that simul- 
taneous reading of both Rams occurs in a legal region illustrated below: 



Ram #2 ^j. 
write address ctr. 



Byte wide Itam 
forVC-3#2 



Common read 
address ctr. 



forYC-3#l 



write address ctti 




On the face of it, to control the read address counter, one waits for the last VC of the two to 
arrive ( when it writes to address 0 ). The read address counter can then trickle along behind 
the write address of #2 above, so long as it doesn't fall so far behind that the write counter of 
#1 catches up with iL Hie problem is that if the system started up, just after #1 had writen to 
address 0, it would think #2 was the first arriving frame and #1 arrived later. This is why the 
sequence number has to run for > twice the designed differential delay. If *last* arrives more 
than the designed value after 'first*, the read address- counter needs resetting. Controlling the 
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read address counter in normal operation should be hitless, so it must be controlled by incre- 
menting faster or slower, not by resetting to a new value. This can be achieved by clock gap- 
ping- 

Note: it may not be necessary for the payload ram to be twice as large as the differential delay, 
but it's a lot easier to think about if it is. 

Note: if the virtually concatenated VCs suffer a differential delay larger than, the range of the 
sequence numbering, this can only be detected by corruption of the payload data. 
Note: This is an example to illustrate the principle, the actual Virtual Concatenation overhead 
is described later. 

Note: Virtual Concatenation overhead is not read, believed and acted on separately for each 
frame; The stream identification ( V03 no. x of a total of y ) is considered to indicate a faultif 
it is not the expected value for ml succesive frames. The sequence number'isr compared to a 
local sequence -counter. Three unexpected sequence numbers in three consecutive frames is 
considered a fault, anicauses the local sequence counter to hunt for a new alignment. Data 
extraction from the virtual concatenated containers is based on the local sequence counter. 
Note: The choice of Virtual Concatenation overhead with its location determined by its place 
in the VC structure precludes the passage of concatenated payloads over PDH links. 

A3: Virtual Concatenation Overhead 

VCS3a»LdVC4 
One column located immediately after the path overhead column. 

• 1st byte ( after Jl ): Stream Number, 1-64 

• 2nd byte ( after B3 ): Total Number of Streams, 1-64 
« 3rd byte ( after C2 ): Sequence Number LSBs 

• 4th byte ( after Gl ): Sequence Number MSBs 

• 5th thru 9th byte: Reserved 

Note: Use of only the LSBs of the sequence number permits +/- 128 frames or +/- 16 mS dif- 
ferential delay. 

VC-12 

One byte immediately following V5 and one byte immediately following N2. 

• Byte following V5: 4 bit Stream Number , 4 bit Total Number of Streams. Binary 6-15 used 
as Stream 1-16. 

• Byte following N2: 8 bit Sequence Number. 

Note: The 8 bit sequence number applies to 500 uS multiframes. This permits +/- 128 multi- 
frames or +/- 64 mS differential delay. 
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